Reverse Proxy

A reverse proxy is a server that sits in front of backend servers and routes client requests to the appropriate server, then returns the response to the client as if it came from the proxy itself.

It is called “reverse” because it works in the opposite direction of a forward proxy (which forwards internal requests to external servers).

Where Does It Sit?

Client --> Reverse Proxy --> Backend Servers

Why Use a Reverse Proxy?

Feature	Benefit
Load Balancing	Distributes traffic across multiple servers to prevent overload.
SSL Termination	Handles HTTPS encryption/decryption so backend servers don’t have to.
Caching	Stores responses to reduce load on backend servers.
Compression	Optimizes data sent to clients, improving performance.
Security (WAF)	Hides backend servers, filters malicious traffic (e.g., DDoS protection).
Routing & Path-based Proxying	Directs requests to the right service or endpoint based on rules.
Authentication	Can require and validate tokens or credentials before passing to backend.

How It Works (Request Flow)

1. User sends a request to a public IP/domain (e.g., https://example.com).

2. The DNS points to the reverse proxy server (e.g., NGINX, HAProxy).

3. The reverse proxy:

   • Checks rules (e.g., load balance, path match).
   • Forwards the request to the correct backend server.

4. The backend processes the request and returns a response.

5. The reverse proxy sends the response back to the user.

Example of reverse proxy

System Design

Client (Browser)
      ↓
NGINX Reverse Proxy (HTTPS)
 ├──> Web Server 1 (Node.js)
 ├──> Web Server 2 (Node.js)
 └──> API Server (Python Flask)

NGINX Reverse Proxy Configuration Example:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://web_servers;
    }

    location /api/ {
        proxy_pass http://api_server;
    }
}

upstream web_servers {
    server 10.0.0.1;
    server 10.0.0.2;
}

upstream api_server {
    server 10.0.0.3;
}

What This Does:

• / path goes to one of the two web servers (load-balanced).
• /api/ path goes to the backend API server.
• Client only knows about example.com, not the internal IPs.

Example of reverse proxy with NGINX

A reverse proxy like NGINX or Traefik is often used in microservices-based architectures to:

• Expose a single entry point (API Gateway style)
• Route /users, /orders, /products to the correct microservices
• Handle authentication, rate limiting, logging, etc.

           ┌─────────────────────────┐
Client --> │   Reverse Proxy (Traefik)  │
           └─────────────────────────┘
              ├── /users  ──> User Service
              ├── /orders ──> Order Service
              └── /cart   ──> Cart Service

Security Benefits

• Backend IPs and ports are never exposed to the public.
• Reverse proxy can act as a Web Application Firewall (WAF).
• Supports rate limiting, IP whitelisting, and DDOS mitigation.

Tools Commonly Used as Reverse Proxies

Tool	Notes
NGINX	Lightweight, widely used, supports caching and load balancing.
HAProxy	High performance, advanced load balancing, used in enterprise.
Apache HTTPD	Can be configured as a reverse proxy.
Traefik	Cloud-native reverse proxy with automatic service discovery.
Envoy	Modern proxy used in service meshes (e.g., Istio).

Reverse Proxy vs Load Balancer

Feature	Reverse Proxy	Load Balancer
Main Function	Routes requests to internal services	Balances traffic load
Visibility	Hides backend logic	Hides server identity
Traffic	Can go to different apps	Goes to same app on multiple instances
Caching	Often used for caching	Rarely used for caching
Security Role	Protects backend, enforces policies	Less focused on security
Common Tools	Nginx, Apache, Traefik	HAProxy, AWS ELB, Nginx, Envoy

Client → Reverse Proxy → Load Balancer → App Servers